The present invention relates generally to smart card terminals. More specifically, the present invention relates to a terminal software architecture that allows terminal applications to be portable to multiple terminals.
In today""s technologically advanced society, businesses often issue cards to consumers for making transactions and so that their purchases and other transactions may be tracked. For example, many businesses currently make use of so-called xe2x80x9cloyaltyxe2x80x9d programs that reward customers for frequent purchase of the business""s products or services. Well known loyalty programs include frequent flyer mileage programs, frequent guest programs at hotels, programs to reward frequent purchases at food markets, etc. Such loyalty programs may make use of a plastic card with an embossed customer number to help keep track of a customer""s purchases. Others use a magnetic stripe card which can magnetically store information such as customer name and identification number, number of purchases, points awarded, etc. Still other loyalty programs have been implemented using a smart card in conjunction with a terminal at a loyalty operator""s place of business. Other software programs that implement stored-value applications, debit applications, etc., (xe2x80x9capplicationsxe2x80x9d) are also implemented using consumer smart cards and terminals at businesses. It is therefore important to ensure that the cards and corresponding terminals are compatible. Although such compatibility has been successfully tested to date, there are a number of disadvantages to the way the testing is currently being performed.
Traditionally, card and terminal suppliers have independently received a functional specification for a new smart card-based application. Working asynchronously and semi-autonomously, the suppliers create card and terminal application programs from the functional specification. However, considerable latitude in the interpretation of the functional specification exists, often resulting in incompatible card and terminal implementations. As a result, additional development and testing time has been required to resolve the discrepancies.
The traditional situation is further aggravated by the complexity of programming chip cards and their low-level interface to the terminal. Therefore, demand for chip card-based applications places considerable pressure on a scarce pool of qualified people generally resulting in an extended time-to-market period.
Typically, the cards and terminals are designed, tested, and produced in parallel. More particularly, the production of a terminal includes manufacture of the back-end system for handling the data for the terminal as well as the terminal application that runs on the terminal. Similarly, the production of a card such as a smart card includes creating the card application (i.e., code) that is to be loaded onto the smart card. Together, the back-end system, terminal application and card application implement the overall application, such as a loyalty application.
FIG. 1 is a diagram illustrating a conventional method of producing compatible card and terminal applications. As shown, an application designer 102 (such as Visa International) produces separate specifications for the card application, the terminal application, and the back-end system that are given to the different corresponding manufacturer and systems developers. The back-end system specification 104 is given to a back-end system developer 110, the terminal application specification 106 is given to a terminal manufacturer 112, and the card application specification 108 is given to a card manufacturer 114 for independent development. Once the back-end system, the terminal application, and the card application are completed, the completed products are provided to the application designer for certification testing. Certification testing 116 is then performed to test the functionality and compatibility of the completed products. Once testing is completed, the products are produced 118.
While the certification process may appear to be straight forward, it is important to note that it is typically desirable to design a card application that is compatible with terminals manufactured by a variety of terminal manufacturers. As a result, the conventional certification process is repeated for each such terminal to verify the functionality of the terminal as well as the compatibility of the terminal with the card application. Accordingly, since the certification process is performed for each different terminal, the certification process is a long and tedious process.
In addition, although the specifications for each of the products (e.g., terminal and card applications) are written such that the resulting products will be compatible, there are often multiple interpretations for a given specification. As a result, there may be discrepancies between the interpretation of a specification and the resulting implementation by a given manufacturer (e.g., terminal and card manufacturers). It is therefore necessary to repeat the certification process until all discrepancies are resolved. This method of production is therefore a time-consuming and expensive one.
As described above, each terminal application is designed and written for use with a specific terminal. That is, a conventional terminal application is typically written using proprietary libraries and software maintained by the terminal manufacturer. FIG. 2 is a diagram illustrating a conventional terminal architecture for terminal A. As shown, a terminal application 202 is specifically designed and written for use with terminal A. In addition, the terminal application 202 directly uses operating system 204. While libraries 206 may serve to standardize such terminal applications, the libraries typically include files that are proprietary to the manufacturer""s development, including hardware 208. As a result, such a terminal application 202 cannot easily be altered to accommodate different terminals.
Although terminal applications cannot easily be altered to be compatible with different terminals, the number and capability of terminals are expanding. In addition to electronic point of sale systems, EFT/POS terminals and ATMs, non-traditional points of interaction require card acceptance in kiosks, personal computers, network computers and consumer applicances such as smart phones, television set-top boxes and advanced electronic game systems.
As described above, while libraries may provide some standardization for the production of terminals and terminal applications, each terminal application must still be written such that it is compatible with a specific operating system and hardware. For instance, a diagram illustrating a conventional terminal architecture for terminal B is illustrated in FIG. 3. A terminal application 210 is written specifically for terminal B, which interacts directly with the operating system 212 provided in terminal B. Similarly, the application 210 uses libraries 214 that are specific to terminal B and the associated hardware 216. Therefore, even where different terminal applications are designed and written to be compatible with the same card application, the terminal applications must also be compatible with the operating system and hardware of the specific terminals. As a result, it is impossible to run the same terminal application on terminals manufactured by different terminal manufacturers. Thus, for a given loyalty application, while there may be a single card application, there may be multiple terminal applications required due to the different types of terminals. For example, terminal applications 202 and 210 are different, yet still implement the same loyalty application.
In view of the above, it would be beneficial if a terminal architecture were developed that would permit terminal and card applications to be developed in parallel such that the resulting applications are guaranteed to be compatible. Moreover, it would be desirable if a terminal application designed for use with a specific card application could be used with different terminals.
The present invention provides methods and apparatus for ensuring compatibility of terminal and card applications produced in parallel, and therefore faster deployment and certification of terminal applications. This is accomplished through providing a terminal architecture that permits terminal applications to be written independent of the operating system and hardware of the terminal.
According to one embodiment of the invention, a terminal software architecture and associated terminal for accepting a smart card implementing a card application of a merchant is presented. Through the use of this terminal architecture, terminal application and card applications can be developed in parallel such that the resulting applications are guaranteed to be compatible. Moreover, through the use of the present invention, a terminal application designed for use with a specific card application can be used with different terminals.
According to one aspect, a terminal software architecture for accepting a smart card that implements a card application of a merchant includes an environment component and a terminal application compatible with the card application and having a platform independent portion that is independent of the environment component. The platform independent portion will be hereinafter referred to as the chip logic component (CLC). The environment component includes hardware of the terminal, an operating system of the terminal, and an environment services layer that supplies one or more environment dependent services dependent upon at least one of the operating system and the hardware of the terminal. Thus, the environment component functions as the platform dependent component of a terminal application.
According to another aspect of the invention, the environment component includes an environment services layer and a business logic layer (BLL). The environment services layer supplies platform dependent services and the BLL represents the policies established, for example, by the entity placing the terminal.
According to yet another aspect of the invention, the terminal architecture further includes a first application programming interface and a second programming interface. The first application programming interface enables the terminal application to communicate with the environment services layer, wherein the environment dependent services provided by the environment services layer are accessible by the platform independent portion of the terminal application through the first programming interface. The second application programming interface enables the business logic layer to communicate with the terminal application. Thus, the CLC can indirectly access terminal equipment using the first application programming interface.
The present invention provides a terminal software architecture which allows a platform independent portion of a terminal application (CLC) to be developed. Since the CLC is platform and environment independent, the CLC is compatible with all terminals implementing the disclosed terminal architecture. This permits application designers to create and deploy a single CLC module that supports an application across all terminals implementing the disclosed architecture. Moreover, since the CLC is compatible with all terminals implementing this architecture, the time required to complete verification testing associated with these terminals is dramatically reduced.